fix(transcription): resample from the real capture sample rate#6
Open
farce1 wants to merge 1 commit into
Open
Conversation
The transcription worker hard-coded a 48kHz->16kHz resampler, but capture falls back to the device's native rate when it can't force 48kHz F32 — notably Bluetooth headset mics (HFP) deliver 16kHz. Those samples were then resampled as if 48kHz, ~3x speed-distorting the audio into garbage ASR. Plumb the actual capture rate (mic in Mic/Both modes, loopback in System) from RecordingState through StartWorkerArgs/WorkerConfig into the resampler. The 48kHz path stays byte-identical; non-48k devices are now correct.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The transcription worker hard-coded a 48 kHz → 16 kHz resampler (
worker.rs), but capture falls back to the device's native rate when it can't force 48 kHz F32 (capture.rs select_mic_config). The most common real case: Bluetooth headset mics in HFP mode deliver 16 kHz (AirPods etc.). Those 16 kHz samples were resampled as if 48 kHz → ~3× speed/pitch distortion → effectively garbage transcripts for a large slice of meeting users. The Opus-encoded OGG already used the real rate, so only the transcription path was wrong.Fix
RecordingStatenow carriestranscription_sample_rate, set from the stream that actually feeds ASR: mic rate in Mic/Both modes, loopback rate in System mode (transcription_source_ratehelper).StartWorkerArgs→WorkerConfig→ the worker'sAudioResampler::new(real_rate, 16k, …)(with a zero-guard fallback to 48 kHz).Verification (TDD)
transcription_source_ratetests — demonstrated RED by mimicking the old hard-coded 48k (tests failedleft: 48000, right: 44100), then GREEN with the real selection.clippy --all-targets --all-features -- -D warnings✅; fullcargo test→ 5 new tests pass, only the pre-existingmodel_archive_consts_tests(REPLACE_WITH_placeholders) fail, unrelated.Note on interaction with #5
With #5 (Both-mode mic+system downmix) also merged, Both mode resamples at the mic rate; if mic and system rates differ, the system half is mis-resampled — the same pre-existing mixed-rate limitation flagged in #5. The common case (both 48 kHz) is correct. A fuller fix is canonical-rate normalization at capture (a larger, riskier change worth a dedicated decision).
mainis red on three maintainer-only release blockers (SHA256/pubkeyREPLACE_WITH_placeholders, uncommittedvendor/vc_redist.x64.exe, separate frontend failure). Verified locally with a temporary untracked vendor placeholder. Do not merge until release prep is complete. Staged Track-A fix from the Handy vs openNotes transcription review; code-only, no new deps.